home *** CD-ROM | disk | FTP | other *** search
/ Gold Medal Software 2 / Gold Medal Software Volume 2 (Gold Medal) (1994).iso / games / cheats / init13a.arj / INT13.DOC < prev   
Text File  |  1986-08-10  |  9KB  |  187 lines

  1.  
  2.  
  3. P                               INT13 DOCUMENTATION
  4.  
  5. P     The file INT13.ARC contains the following:
  6.  
  7. P                       INT13.ASM - Source file for INT13.COM
  8. P                       INT13.COM - Resident interrupt 13h handler
  9. P                       INT13.DOC - This documentation file
  10.  
  11.  
  12. P         I. Function of INT13.COM
  13.  
  14. P         INT13.COM is a resident "front-end" program which intercepts ROM
  15. P     BIOS interrupt 13h calls to perform disk functions on specific sectors.
  16. P     INT13.COM prints out the requested disk drive, side, track, sector,
  17. P     number of sectors, and operation type contained in the registers.  After
  18. P     the interrupt processing is completed, INT13.COM prints the status code
  19. P     returned (which indicates whether an error has occured), and the address
  20. P     in the calling program to which control will be returned.
  21.  
  22.  
  23. P         II. Purpose of INT13.COM
  24.  
  25. P         INT13.COM was written as a tool to help unravel copy protection
  26. P     schemes, virtually all of which use interrupt 13h to look for weirdly-
  27. P     formatted tracks on the original "key" diskette.  This utility allows
  28. P     you to find out - without searching through a disassembly of the program
  29. P     - what the copy protection scheme is looking for on the key diskette.
  30. P     The return address printed shows where (or, more accurately, the point
  31. P     immediately after) the call to interrupt 13h was made.  This can be
  32. P     especially useful where the copy protection scheme trys - as many do -
  33. P     to disguise the interrupt call so as to thwart casual attempts to defeat
  34. P     the protection.
  35.  
  36. P         I will not attempt to provide information on the various codes
  37. P     associated with interrupt 13h processing since this information is
  38. P     available in any book on IBM Assembly Language or in the IBM Technical
  39. P     Reference manuals.  In general, however, a few things to look for in a
  40. P     protection scheme are:
  41.  
  42. P            a.  Sector numbers greater than 9.
  43.  
  44. P            b.  Sectors deliberately formatted with CRC errors.  The pro-
  45. P                tection scheme either "reads" (operation code 02) or "veri-
  46. P                fies" (operation code 04) the sectors.  The program then
  47. P                expects to get a return code of 10, indicating the sectors do
  48. P                indeed contain CRC errors.
  49.  
  50. P            c.  Multiple calls for the same sector.  Some schemes format a
  51. P                track with two sectors with the same number.
  52.  
  53.  
  54. P         III. Using INT13.COM
  55.  
  56. P         Before executing the program to be examined, simply run INT13.  A
  57. P     short message will be displayed indicating that the program has been
  58. P     installed.  Be sure to reboot your computer after finishing your work
  59. P     with INT13.  Also take care not to install INT13 more than once (between
  60. P     reboots).  I haven't written in any safeguards against multiple in-
  61. P     stalls, although a future version may have this feature.
  62.  
  63.  
  64.  
  65. P         If you are not using DEBUG, then simply execute your program.  A log
  66. P     of the disk activity will then be printed.  Program loading and execu-
  67. P     tion will be slowed due to the time required for printing.
  68.  
  69. P         If you are using DEBUG, then proceed as you would normally.  The
  70. P     addresses reported on the disk activity log will correspond to the
  71. P     locations in the program being debugged so you may immediately see where
  72. P     the calls are being made.
  73.  
  74. P         It is advisable to run INT13 with your program more than one time
  75. P     since some protection schemes select different tracks for checking on a
  76. P     random basis.
  77.  
  78. P         Note: Since copy protection schemes rarely, if ever, check other
  79. P     than the "A" diskette drive, INT13 is set up to log only calls to that
  80. P     drive.  If you wish disk activity on all drives to be logged, remove the
  81. P     instructions listed in the source code and reassemble the program.
  82.  
  83.  
  84. P         IV.  Interpreting the results
  85.  
  86. P         This is the hardest part.  If you are going to become an accom-
  87. P     plished "unprotector" you will have to have at least a passing knowledge
  88. P     of assembly language.  INT13 will point you to the part(s) of the pro-
  89. P     gram doing the protection verification and will show you what the pro-
  90. P     gram expects to find.  It's up to you to figure out how to bypass the
  91. P     protection.  This can be quite easy, sometimes only requiring a branch
  92. P     around the code doing the protection verification, or it can involve
  93. P     hours of single-stepping through the program for really devious
  94. P     protection schemes.  Either way, INT13 should speed up things.
  95.  
  96.  
  97. P         V.  Caveats
  98.  
  99. P         Since INT13 functions under DOS's control, this utility will not
  100. P     always function with some game programs which have their own operating
  101. P     system on the disk.
  102.  
  103. P         INT13 also doesn't work with PROLOK-protected diskettes.  Apparently
  104. P     PROLOK assigns interrupt 13h to some other interrupt number (at least
  105. P     this is my guess).
  106.  
  107.  
  108. P         VI.  How INT13 works
  109.  
  110. P         When you run INT13, the vector in low memory which normally points
  111. P     to the ROM BIOS routine for interrupt 13h is changed to point to the
  112. P     front-end processing contained in INT13.  When your program issues an
  113. P     interrupt 13h call, control goes first to INT13 and the required
  114. P     information is stored for later printout.  Control is then passed to the
  115. P     normal interrupt 13h routine.  When the I/O processing is finished,
  116. P     INT13 regains control and prints the log data, including the return code
  117. P     passed back.  Finally, control returns to the calling program.  If you
  118. P     are interested in further details, examine the source code.
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127. P         VII.  How some protection schemes attempt to disguise interrupt 13h
  128. P               calls
  129.  
  130. P         If you are attempting to unprotect a program, the usual course of
  131. P     action is to search for occurences of "CD13", which is machine language
  132. P     for interrupt 13h.  One way or another, the protection scheme will have
  133. P     to use this interrupt to check for the special sectors on the disk.  If
  134. P     you examine a cross section of programs, however, you will find programs
  135. P     which do not have "CD13" in their machine code, but which clearly are
  136. P     checking the key diskette for weird sectors.  How is this being done?
  137.  
  138. P         There are several techniques which can be used to camouflage the
  139. P     protection scheme from prying eyes.  I'll describe below two such
  140. P     techniques I have come across:
  141.  
  142. P         a.  The following section of code is equivalent to issuing a INT 13
  143. P             command to read one sector from: drive A, side 0, track 28h,
  144. P             sector ffh, and then checking for a status code of 10h:
  145.  
  146. P             XXXX:1000 MOV AH,02                  ;read operation
  147. P             XXXX:1002 MOV AL,01                  ;1 sector to read
  148. P             XXXX:1004 MOV CH,28                  ;track 28h (40d)
  149. P             XXXX:1006 MOV CL,FF                  ;sector ffh (255d)
  150. P             XXXX:1008 MOV DX,0000                ;side 0, drive A
  151. P             XXXX:100B XOR BX,BX                  ;move 0
  152. P             XXXX:100D MOV DS,BX                  ;       to DS register
  153. P             XXXX:100F PUSHF                      ;push the flags onto stack
  154. P             XXXX:1010 PUSH CS                    ;push the CS register
  155. P             XXXX:1011 CALL 1100                  ;push addr. of next instr.
  156. P                                                  ; onto stack and branch
  157. P             XXXX:1014 CMP AH,10                  ;check for CRC error
  158. P             XXXX:1017 rest of verification code
  159. P                  .
  160. P                  .
  161. P                  .
  162. P             XXXX:1100 PUSHF                      ;push the flags onto stack
  163. P             XXXX:1101 MOV BX,004C                ;addr. of int 13h vector
  164. P             XXXX:1104 PUSH [BX+02]               ;push CS of int13h routine
  165. P             XXXX:1107 PUSH [BX]                  ;push IP of int13h routine
  166. P             XXXX:1109 IRET                       ;pop IP,CS and flags
  167.  
  168. P             Notice that there is no "INT 13" command in the source code, so
  169. P             if you had simply used DEBUG to search for "CD13" in the machine
  170. P             code, you would never have found the protection routine.
  171.  
  172.  
  173. P         b.  Another technique is to put in a substitute interrupt instruc-
  174. P             tion (such as INT 10, which looks harmless enough), and have the
  175. P             program change the "10" to "13".  A search for "CD13" would turn
  176. P             up nothing.
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.